GermanWikipedia - /page/entry.mu

Micron Document

<!DOCTYPE html>

<title>Robustheitsanalyse</title>

</head>

<h1 id="firstHeading" class="firstHeading mw-first-heading"><span class="mw-page-title-main">Robustheitsanalyse</span></h1>

</header>

</div>

<p>Die <b>Robustheitsanalyse</b> ist ein Verfahren in der <a href="Softwaretechnik" title="Softwaretechnik">Softwaretechnik</a>, mit dem man <a href="Anwendungsfall" title="Anwendungsfall">Anwendungsfälle</a> auf verschiedene Aspekte untersuchen kann. Dabei wird der vorhandene Text des Anwendungsfalls analysiert und in seine Bestandteile zerlegt. Als Ergebnis der Analyse wird ein <b>Robustheitsdiagramm</b> erstellt, welches im Grunde einem vereinfachten <a href="Kollaborationsdiagramm" class="mw-redirect" title="Kollaborationsdiagramm">Kollaborationsdiagramm</a> entspricht. <br>

Durch die Anwendung der Analyse wird in erster Linie ein <a href="Sanity_Check" title="Sanity Check">Sanity Check</a> des Anwendungsfalls durchgeführt. Es wird geprüft, ob der Text in sich schlüssig ist oder irrationale Abläufe möglich sind. Dabei können auch weitere Objekte im Domänenmodell gefunden werden, die vorher nicht im Fokus waren. Ebenfalls hilft die Robustheitsanalyse, fehlende Alternativrouten im Text des Anwendungsfalls aufzudecken, zum Beispiel wenn ein Vorgang fehlschlägt.

</p><p>Die Robustheitsanalyse schließt die Lücke zwischen der reinen Analyse (Anwendungsfall – Was soll geschehen?) und dem Design (Sequenzdiagramm – Wie soll es geschehen?). Durch konsequente Analyse aller Anwendungsfälle wird aus dem ursprünglichen Domänenmodell ein Klassenmodell. Aus einem Klassenmodell wiederum kann mit geeigneten Werkzeugen der Rumpfcode der Anwendung automatisch generiert werden.

</p>

<div class="mw-heading mw-heading2"><h2 id="Bestandteile">Bestandteile</h2></div>

<p>Die Robustheitsdiagramme bestehen aus drei unterschiedlichen Objekten und dem Akteur. Die Objekte werden mit einer einfachen Linie verbunden. Zwischen den Objekten kann allerdings auch eine Aggregation vorliegen, wenn zum Beispiel das Boundary-Objekt „Ok-Schaltfläche“ Teil des Boundary-Objektes „Homepage“ ist.

</p>

<div class="mw-heading mw-heading3"><h3 id="Boundary-Objekt">Boundary-Objekt</h3></div>

<ul><li>Bilden die Schnittstelle zwischen Akteur und dem System</li>

<li>Repräsentieren meistens Schaltflächen, Eingabefelder, aber auch ganze Dialoge oder Menüs</li>

<li>Sollten leicht <a href="Anwendungsfall" title="Anwendungsfall">Anwendungsfall</a>-Texten entnommen werden können</li>

<li>Sind Substantive im Text des Anwendungsfalls</li></ul>

<div class="mw-heading mw-heading3"><h3 id="Entity-Objekt">Entity-Objekt</h3></div>

<ul><li>Repräsentieren Objekte aus dem Domänenmodell</li>

<li>Oft entsprechen sie Datenbanktabellen</li>

<li>Die Information, die von dem Objekt gehalten wird, überlebt den Anwendungsfall</li>

<li>Sind Substantive im Text des Anwendungsfalls</li></ul>

<div class="mw-heading mw-heading3"><h3 id="Control-Objekt">Control-Objekt</h3></div>

<ul><li>Werden als Steuerungsobjekte zwischen Boundary und Entity verwendet und auch Controller genannt</li>

<li>Sind als Verben im Text des Anwendungsfalls zu finden</li>

<li>Oft werden Controller erst als Platzhalter benutzt, die später durch Methoden von Boundary / Entity-Objekten ersetzt werden</li></ul>

<div class="mw-heading mw-heading3"><h3 id="Akteur">Akteur</h3></div>

<ul><li>Der Akteur interagiert mit dem System</li>

<li>In der Regel stellt der Akteur einen späteren Endanwender dar</li></ul>

<div class="gallerytext">Boundary</div>

</li>

<div class="gallerytext">Entity</div>

</li>

<div class="gallerytext">Controller</div>

</li>

<div class="gallerytext">Akteur</div>

</li>

</ul>

<div class="mw-heading mw-heading2"><h2 id="Regeln">Regeln</h2></div>

<p>Es gibt vier grundlegende Regeln, die man bei Erstellung der Diagramme beachten muss:

</p>

<ol><li>Akteure können nur mit Boundary-Objekten kommunizieren</li>

<li>Boundary-Objekte können nur mit Akteuren und Controllern kommunizieren</li>

<li>Entity-Objekte können nur mit Controllern kommunizieren</li>

<li>Control-Objekte können mit Boundary, Entity und anderen Controllern kommunizieren, jedoch nicht mit Akteuren</li></ol>

<div class="mw-heading mw-heading2"><h2 id="Richtlinien">Richtlinien</h2></div>

<p>Im Allgemeinen sollte man die Analyse und den Modellierungsgrad nicht übertreiben. Es soll eher als integrierter Schritt nach dem Erstellen der <a href="Anwendungsfall" title="Anwendungsfall">Anwendungsfälle</a> verstanden werden, anstatt einer eigenständigen und unabhängigen Analyse.

In einem Artikel des „Software Development Magazine“ haben Kendall Scott und Doug Rosenberg die häufigsten / typischen Fehler analysiert und Vorgehensweisen beschrieben wie diese zu umgehen sind. Hier die wichtigsten als allgemeine Richtlinien, zum Erstellen von Robustheitsdiagrammen, formuliert:

</p>

<ul><li>Man sollte das statische Domänenmodell nach den Erkenntnissen der Robustheitsanalyse aktualisieren (neu gefundene Objekte eintragen)</li>

<li>Es sollte ein visueller Abgleich zwischen der Beschreibung der Anwendungsfälle und dem Robustheitsdiagramm stattfinden (Lesen des Textes der Anwendungsfälle und gleichzeitiges Nachvollziehen im Diagramm)</li>

<li>Man sollte nicht zu viele Controller-Objekte in die Diagramme einbauen, die Robustheitsanalyse soll ein schneller „Sanity Check“ für die Anwendungsfälle sein.</li>

<li>Alternative Wege aus dem Anwendungsfall (z. B. im Fehlerfall) sollten ebenfalls dargestellt werden</li></ul>

<div class="mw-heading mw-heading2"><h2 id="Beispiel">Beispiel</h2></div>

<p>Hier ein Beispiel <a href="Anwendungsfall" title="Anwendungsfall">Anwendungsfall</a> in verkürzter Form:

<br>

Name des Anwendungsfalls: Anmeldung

<br>

Beschreibung: Nutzer meldet sich an Mitgliederseite an

<br>

Beteiligte Akteure: Mitglied, Webserver, Nutzerdatenbank

<br>

Ablaufschritte (normaler Ablauf):<br>

</p>

<ul><li>Der Benutzer gibt Nutzernamen und Kennwort auf der Anmeldeseite ein und betätigt die Schaltfläche „Ok“.</li>

<li>Das System vergleicht die eingegebenen Daten mit denen in der Benutzerdatenbank und liefert die Mitgliederseite.</li></ul>

<p><br>

Beim Abgleich zwischen Text und Diagramm sollten parallel der Text gelesen und die Aktionen im Diagramm verfolgt werden. An dieser Stelle wird auch sichtbar, dass man keine Alternative für den Fall modelliert hat, dass die Daten des Benutzers nicht korrekt eingegeben wurden.

</p>

<div class="mw-heading mw-heading2"><h2 id="Weblinks">Weblinks</h2></div>

<ul><li><a rel="nofollow" class="external text" href="https://www.agilemodeling.com/artifacts/robustnessDiagram.htm">Agile Modeling - Robustness Diagrams</a></li>

<li><a rel="nofollow" class="external text" href="http://www.codeproject.com/aspnet/ModelViewController.asp">Applying Robustness Analysis on the Model–View–Controller (MVC) Architecture in ASP.NET Framework, using UML</a></li></ul></div><div><div class="zim-footer">

Dieser Artikel wurde von <a class="external text" title="Zuletzt bearbeitet am 2025-12-14" href="https://de.wikipedia.org/wiki/?title=Robustheitsanalyse&oldid=262420273">Wikipedia</a> herausgegeben. Der Text ist unter <a class="external text" href="https://creativecommons.org/licenses/by-sa/4.0/deed.de">Creative Commons Attribution-Share Alike 4.0</a> verfügbar, sofern nicht anders angegeben. Für die Mediendateien können zusätzliche Bedingungen gelten.

</div>

</div></div>

</div>

</main>

</div>

</body></html>